home *** CD-ROM | disk | FTP | other *** search
- Path: engnews1.Eng.Sun.COM!taumet!clamage
- From: gregor@netcom.com (Greg Colvin)
- Newsgroups: comp.std.c++
- Subject: Re: sample auto_ptr template
- Date: 11 Apr 1996 14:53:32 GMT
- Organization: Netcom Online Communications Services (408-241-9760 login: guest)
- Approved: clamage@eng.sun.com (comp.std.c++)
- Message-ID: <gregorDppDEJ.Jpz@netcom.com>
- References: <009A0A5CE1159CC0.49802F14@ittpub.nl> <gregorDpoGM2.Hw2@netcom.com>
- NNTP-Posting-Host: taumet.eng.sun.com
- Apparently-To: comp-std-c++@uunet.uu.net
- Content-Length: 1140
- X-Lines: 31
- Originator: clamage@taumet
-
- In article <gregorDpoGM2.Hw2@netcom.com> gregor@netcom.com (Greg Colvin) writes:
- >
- >Pre April, an auto_ptr silently changed into a null pointer after
- >copying, except that trying to copy it was ill-formed. Post April
- >copying is allowed. Derereferencing a null pointer gives undefined
- >behavior, as does dereferencing a pointer to a deleted object, so I
- >don't see such a big difference. Given
- > void f(auto_ptr<T>);
- > auto_ptr<T> p(px);
- >then before April we had
- > f(p); // unintentionally ill-formed
- > p->whatever(); // undefined behavior
- >and after April we have
- > f(p); // well-formed
- > p->whatever(); // possibly undefined behavior
-
- Silly me. Of course that should be:
- ... Given
- void f(auto_ptr<T>);
- auto_ptr<T> g();
- auto_ptr<T> p;
- then before April we had
- p = g(); // unintentionally ill-formed
- f(p);
- p->whatever(); // undefined behavior
- and after April we have
- p = g(); // well formed
- f(p);
- p->whatever(); // possibly undefined behavior
-
- I hope I got it right this time :-)
-
-
- [ comp.std.c++ is moderated. To submit articles: try just posting with ]
- [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
- [ FAQ: http://reality.sgi.com/employees/austern_mti/std-c++/faq.html ]
- [ Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
- [ Comments? mailto:std-c++-request@ncar.ucar.edu ]
-